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(54) A configurable vending machine audit module 



(57) A method of auditing data from a vending ma- 
chine includes providing commands to an audit module 
installed in the vending machine. The commands indi- 
cate a type of vending machine data to be processed by 
the audit module, how the data is to be processed by 
the audit module, and a location in memory in the audit 



module for storage of that type of vending machine data. 
The audit module is configured to process vending ma- 
chine data in response to the received commands. Mon- 
itored vending machine data can be reported to a re- 
mote host in a manner specified by one or commands 
sent to the audit module. 
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Description 

BACKGROUND 

[0001] The present invention relates generally to the 
monitoring and reporting ot vending machine data and, 
in particular, to a configurable vending machine audit 
module. 

[0002] Various forms of monitoring and reporting sys- 
tems are often associated with vending machines. Such 
systems can provide periodic monitoring and reporting 
of various events within the machines, such as inventory 
changes, maintenance requirements, service calls, 
cash receipts, demand for specific products, sold-out 
conditions, and various alarm conditions, among others. 
[0003] Some monitoring and reporting systems in- 
clude a central computer complex which receives data 
from multiple vending machines at remote locations. In 
such systems, a communication link is established be- 
tween the central computer and the individual machines 
through the use, for example, of standard telephone 
lines or radio communications. At predetermined inter- 
vals, each vending machine accesses the communica- 
tion link and calls the central computer. Once commu- 
nication is established, the vending machine can trans- 
mit pertinent information about its status. Such systems 
can help eliminate unnecessary service calls and facil- 
itate better supply route planning. The monitoring and 
reporting systems can lead to improved auditing prac- 
tices as well as increased sales. 

[0004] Generally, the vending machine and the cen- 
tral computer communicate using a predefined protocol 
which may include, for example, a series of fixed pack- 
ets each of which is designed to contain a predeter- 
mined type of information. Such techniques can make 
it difficult to change the types of data that are reported 
by the vending machine because new software must be 
provided to the vending machine reporting unit to allow 
the desired data to be collected and reported. Accord- 
ingly a technique which simplifies the process for con- 
figuring and reconfiguring a vending machine data mon- 
itoring and reporting unit so that different types of data 
can be collected and reported is desirable. 

SUMMARY 

[0005] In general, according to one aspect, a method 
of auditing data from a vending machine includes pro- 
viding commands to an audit module connected to the 
vending machine. The commands are generated exter- 
nally and indicate a type of vending machine data to be 
processed by the audit module, how the data is to be 
processed by the audit module, and a location in mem- 
ory in the audit module for storage of that type of vending 
machine data. The method also includes configuring the 
audit module to process vending machine data in re- 
sponse to the received commands. 
[0006] According to another aspect, an audit module 



arranged for connection to a vending machine includes 
a controller and memory. The audit module is configured 
to receive externally-generated commands indicating a 
type of vending machine data to be processed by the 
$ audit module, how the data is to be processed by the 
audit module, and a location in the audit module memory 
for storage of that type of vending machine data. The 
audit module is configured to process vending machine 
data based on the received commands. 
10 [0007] Some implementations include one or more of 
the following features. The commands can be transmit- 
ted to the audit module from a remote host. The audit 
module can be configured, for example, to report vend- 
ing machine data to the remote host based on the re- 
's ceived commands. The audit module also can be con- 
figured to store at least one command which is to be 
executed by the audit module upon the occurrence of a 
specified event. Similarly, the audit module can be con- 
figured to store a stack of commands which are to be 
executed by the audit module upon the occurrence of 
one or more specified events. 

[0008] The commands can specify vending machine 
data that is to be selectively retained for processing by 
the audit module. In addition, in response to one or more 
of the commands, a removably coupled device in the 
vending machine can be accessed. For example, the 
removably coupled device can be polled to retrieve in- 
formation stored therein. Requested information can be 
transmitted from the audit module to a host. Accessing 
the removably coupled device can include updating, 
modifying or replacing software in the removably cou- 
pled device. 

[0009] The audit module memory also can be recon- 
figured in response to received commands. Thus, oper- 
ation of the audit module can be modified or changed. 
Reconfiguring the memory can cause the audit module 
to execute an operation with respect to vending machine 
data. In some implementations, each command has a 
syntax that includes variables whose values can be se- 
lected from among multiple options. 
[0010] In various implementations, one or more of the 
following advantages may be present. The data to be 
monitored by the vending machine audit module and 
transmitted to the host can be changed dynamically 
without having to upgrade or modify the software code 
or replace a semiconductor chip in the audit module. A 
great amount of flexibility can, therefore, be provided 
with respect to monitoring and reporting vending ma- 
chine data. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] FIG. 1 illustrates an audit system according to 
the invention. 

[0012] FIG. 2 illustrates an audit module according to 
the invention. 

[0013] FIGS. 3A and 3B illustrate an exemplary use 
of the command structure according to the invention. 
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[0014] FIG. 4 is a list of exemplary databases, tables 
and queues in the audit module and their corresponding 
values. 

[0015] FIG. 5 illustrates the structure of an Action 
byte. 

[0016] FIGS. 6-19, 20A-20B, 21 and 22A-22B illus- 
trate the structure of various databases and tables in the 
audit module. 

[0017] FIG. 23 illustrates the format of various com- 
mands for configuring and obtaining information from 
the audit module. 

[0018] FIG. 24 illustrates a format for data transmis- 
sions from the audit module to a host. 
[001 9] FIG. 25 illustrates various interfaces for trans- 
ferring data between the audit module, a host and vend- 
ing machine components. 

DETAILED DESCRIPTION 

[0020] As shown in FIGS. 1 and 2, an audit module 
30 is arranged for installation in and connection to a 
vending machine 32 to monitor events associated with 
the vending machine and to provide audit functions re- 
lating to the monitored activities. The audit module 30 
can be used with various types of vending machines, 
and different interfaces are used to allow the audit mod- 
ule to monitor the signals associated with different ma- 
chines. 

[0021] The audit module 30 includes a controller 58 
that operates according to a pre-loaded software pro- 
gram stored, for example, in non-volatile flash memory. 
The audit module, however, does not have a default 
configuration that represents a standard vending ma- 
chine type. Rather, the audit module is configured for 
the particular environment within which it is to be used. 
The audit module can be configured by a remote host 
34, such as a personal computeror a hand-held module, 
to store data obtained from the vending machine. The 
audit module 30 can report the contents of its databases 
to the host 34 upon request or at previously scheduled 
times. The audit module and the host can communicate, 
for example, using hardwired, infrared, optical, wireless 
or other techniques. 

[0022] The configuration parameters for the particular 
vending machine 32 can be downloaded to the audit 
module 30 at the time of manufacture or upon installa- 
tion into the vending machine. Moreover, the configura- 
tion of the audit module 30 can be modified subsequent- 
ly by a vendor. The configuration parameters are initially 
received and verified, for example, in random access 
memory (RAM) in the audit module and subsequently 
are stored in flash memory. 

[0023] The audit module 30 can be treated as a data- 
base manager which can be queried. A command lan- 
guage is used to manipulate data within database struc- 
tures and to define other fixed structure information such 
as header data. The basic design of the database struc- 
ture is to have mapping information stored in one set of 



database tables and the tracked values in separate da- 
tabases. The index of a particular table references the 
corresponding index of the database. A data field that 
is not configured will not be monitored, and a request 
$ for a database location for which the corresponding 
mapping location has not been configured will result in 
an error. 

[0024] When the audit module 30 is installed in a 
vending machine 32, vending machine data is received 
10 by a buffer 36 (FIG. 2) in the audit module. The audit 
module 30 then stores the received data in one of sev- 
eral databases depending on how the various databas- 
es have been configured. If the audit module 30 is not 
configured to store the received data in any of the data- 
's bases, the data is discarded. 

[0025] The audit module 30 includes several mapping 
tables which are used to determine whether and where 
received vending machine data is to be stored. The 
mapping tables define the information, if any, that is to 
be stored in each of the various databases. The map- 
ping information is configurable at any time and deter- 
mines the information stored in the corresponding data- 
base. 

[0026] The host 34 communicates with the audit mod- 
ule 30 using a command language. The command lan- 
guage allows data stored in various audit module data- 
bases to be manipulated and certain fixed information 
to be defined. Exemplary commands include READ and 
WRITE, among others discussed below. The syntax for 
the commands includes defining the command, speci- 
fying the data structure to which the command applies, 
and specifying index and field references within the da- 
tabase or table. 

[0027] To configure the audit module's databases and 
tables for operation, the host sends configuration infor- 
mation using, for example, the WRITE command. Con- 
figuration information can be directed to various map- 
ping tables to initialize the database structures to store 
specified vending machine data. 

[0028] For example, to track the total cash based on 
data received from the vending machine via an electron- 
ic interface 38, the general mapping structure shown in 
FIG. 3A can be used. Each type of data record received 
from the vending machine via the electronic interface is 
identified by a corresponding block identification (ID). 
For example, data following a specific block identifica- 
tion (ID) may correspond to cash data. Upon receiving 
a WRITE command, for example, the audit module 30 
writes the specified block identification (ID) and field (f) 
into a specified index (n) of a particular mapping table. 
When data from the vending machine 32 subsequently 
is received via the electronic interface 38 and identified 
based on the identification block (ID), the audit module 
30 searches all the mapping table entries for the identi- 
fication block (ID). Based on the entry in the particular 
mapping table, data associated with the specified block 
identification (ID) and field (f) is stored by the audit mod- 
ule 30 in the specified index (n) of one of the databases 
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(FIG. 3B). 

[0029] The host 34 can use a READ command to re- 
trieve information stored in the various databases and 
tables. The host can, therefore, retrieve vending ma- 
chine data stored by the audit module as well as the con- 
figuration parameters currently stored in the various 
mapping tables and databases. The audit module 30 ex- 
ecutes the received command and sends a response 
with the requested information to the host 34. Multiple 
information requests or responses can be included in a 
single transmission. 

Databases and Mapping Tables 

[0030] FIG. 4 is a list of various databases and tables 
and their corresponding values. Each database is con- 
figurable, except for the Configuration Database. The 
databases are formatted with the low byte first. An 'Ac- 
tion' byte is used to define how the data in a particular 
database will be processed. Exemplary 'Action' byte val- 
ues and their associated actions are illustrated in FIG. 
5. For example, an 'Action' byte may indicate that the 
new data is to be added to or subtracted from a previ- 
ously stored value. In some cases, the new data may 
replace the previously stored value. The various data- 
bases and tables are discussed in greater detail below. 
[0031] The Configuration Database 40 includes up to 
forty elements as indicated by FIG. 6. The Configuration 
Database is used to store configuration information 
about the vending machine and the audit module. Some 
entries are used to specify various timeout periods (e. 
g., power loss), to identify the coin and bill types and 
denominations handled by the vending machine, or to 
specify certain hardware configuration flags. A com- 
mand for setting up the hardware configuration flags in- 
cludes an identification of the type of interface to the 
vending machine. Receipt of such a command informs 
the audit module as to the type of interface over which 
it will receive the monitored signals and data from the 
vending machine and, in conjunction with support soft- 
ware stored in flash memory, allows the audit module to 
establish communication channels. 
[0032] The Product Database 42 is defined as a 120 
element database and allows tracking of data relating 
to individual product-types stored in the vending ma- 
chine 32. Each element of the Product Database is de- 
fined by the structure shown in FIG. 7. The field 'Price' 
is a 16-bit unsigned integer and accepts configuration 
commands using values with an implied decimal place 
of 2. The field 'Cumm. Inv' contains a running summa- 
tion of vends forthe product assigned to its position. This 
field is also an unsigned 16-bit field. The field 'Abs. Inv' 
holds the count of items to be vended from its position 
and is a countdown counter. The field 'Sold Out' contains 
an incremental count of the number of times the data- 
base element was selected and no product vended be- 
cause the product was sold out. That counter is also an 
unsigned 16-bit integer. 



[0033] The field 'Dep. Calc.' in the Product Database 
structure is a 1-bit flag field which can be set to cause 
the database element to be included in the calculation 
of over-all machine depletion levels. The field 'CJ Alarm' 

5 is a 1 -bit flag field which can be set to instruct the audit 
module to generate an alarm when a column jam con- 
dition occurs for the associated product. The field 'Warn. 
Lvl.' is an unsigned 6-bit field which allows a warning 
level to be set for product depletion. The field 'Prod. 

10 Trkg.' is a 1 -bit flag field which can be set to cause the 
audit module to track product vends for the database 
element in real time. The field 'Sold Out Alarm' is a 1 -bit 
flag field which can be set to instruct the audit module 
to generate an alarm when a sold out condition occurs 

15 for the associated product. The field 'Crit. Lvl.' is an un- 
signed 6-bit field which can be used to set a critical level 
for product depletion. 

[0034] Two mapping tables are associated with the 
Product Database 42: the Product Mapping Table 50 

20 and the Product Field Mapping Table 52. 

[0035] The Product Mapping Table 50 is a 120 ele- 
ment table used to map the product index to a product 
label. The database contains only one field (see FIG. 9). 
A product can be tracked and reported using a product 

25 label which consists of alphanumeric characters. For ex- 
ample, to monitor row 10, column 4 of a matrix vendor, 
the product label would be 'R10C04.' 
[0036] The Product Field Mapping Table 52 is used to 
store search strings and actions associated with field 

30 data in the Product Database (see FIG. 8). The informa- 
tion is common across the entire Product Database, and 
the index number of this database corresponds to the 
field number of the Product Database. Alarm-enable bits 
in the 'Action' byte are ignored by the Product Field Map- 

35 ping Table as product alarm enable bits are in the prod- 
uct database for each product index. 
[0037] A Cash Database 44 includes approximately 
114 32-bit elements, each of which is a counter or reg- 
ister. Some of the counters and registers can be config- 

40 ured, for example, to keep track of the number of coins 
and bills received or dispensed and to keep track of the 
number of sales. Some of the counters or registers are 
user-defined. The structure of each element in the Cash 
Database is illustrated in FIG. 10. 

45 [0038] A Cash Mapping Table 54 is used to define 
which fields of the Cash Database will be used, the 
name that will be used to access a particular field, and 
how the contents of the field will be handled when ac- 
cessed. The mapping structure ; which is shown in FIG. 

50 n, has an index associated with each index of the Cash 
Database 44. The 'Block ID' and 'Field' values reference 
the search strings and location within the information 
from the vendor. The 'Array Index' field references the 
data location if more than one instance of the datatype 

55 exists for the same record structure. The 'Action' byte 
specifies the operation that should be performed on the 
data. Thus, for example, some records are repeated for 
each coin type. A '0' in the 'Array Index' field would in- 
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dicate that the specified action is to be performed with 
respect to nickels and a '1 1 would indicate that the action 
is to performed with respect to dimes. 
[0039] A Vendor Asset Information Database is used 
to capture asset information from the vendor. Each ele- 
ment of the Vender Asset Information database is rep- 
resented by a single character index that is used both 
in setting up and retrieving data from the database. 
[0040] A Vendor Asset Mapping Table is used to map 
configured database indices to the actual database 
field. In other words, it is used to store the Block ID and 
fields for the appropriate index location in the Vendor 
Asset Information Database. The table consists of twen- 
ty-eight elements, each of which has the structure 
shown in FIG. 1 3. 

[0041] A Vendor Access Database contains personal 
identification numbers (PINs) for authorized users of the 
vending machine. The structure of the database is 
shown in FIG. 14. 

[0042] Several databases and tables are associated 
with event and error information: (1) Events Database; 
(2) Event Database Mapping Table; and (3) Errors/Cus- 
tom Database. 

[0043] The Events Database 46 is a forty-element da- 
tabase, where each element is a counter. The structure 
of the database is illustrated in FIG. 15. Each element 
can be used to monitor various errors or other vending 
machine events, such as power outages, door openings 
and closings, etc. 

[0044] The Events Database Mapping Table 56 is 
used to define which vendor events will be monitored. 
The 'Action' byte indicates how the field will be handled 
when processed, and whether the event being captured 
will be reported in real-time. The mapping structure has 
an element associated with each element of the Events 
Database. The structure of an element in the Events Da- 
tabase Mapping structure is shown in FIG. 16 
[0045] The Errors/Custom Database is a two-part da- 
tabase, whose structure is illustrated in FIG. 17. The first 
part, at index 1 , consists of one 32-bit, bit-addressable 
error field. The second part, starting at index 2, is a var- 
iable-length field for capturing data of unspecified 
length. The second part is, therefore, a dynamic self- 
defining structure whose form depends upon the data 
types being reported. 

[0046] Two mapping tables are used to determine the 
contents of the Errors-Custom database: (1 ) E rrors Cus- 
tom Capture Mapping; and (2) Errors Bit Field Mapping. 
[0047] The Errors Bit Field Mapping Table relates to 
index 1 of the Errors/Custom Database and contains 
thirty -two elements (see FIG. 19). Each contains the AS- 
CII 'Block ID' of the bit being mapped and the 'Action'. 
The actual bit information is determined based upon the 
vending machine controller interface. The elements in 
the Errors Bit Field Mapping structure have a one-to-one 
correspondence with the 'Error Bit Field in the Errors/ 
Custom Database. Index 1 serves as the most signifi- 
cant bit of the most significant word of the mapped field. 



[0048] The Errors Custom Capture Mapping Table de- 
fines the DEX labels of the data being captured for stor- 
age in the second part of the Errors/Custom Database. 
The table is a twenty element structure whose elements 

5 are defined as shown in FIG. 18. 

[0049] A Stored Commands Database contains a list 
of commands that can be run at a time specified by the 
user. The database contains sixteen elements having 
the structure shown in FIG. 20A. The 'Report Type' is 

10 defined as shown in FIG. 20B. The most significant bit 
of the 'Report Type' is used to specify whether a time 
stamp should be placed in the scheduled queue before 
the result. If the most significant bit is set, the time stamp 
is enabled. In one application, stored commands can be 

15 used to report vending machine data at a specified later 
time or upon the occurrence of a particular event, rather 
than at the time the command is sent to the audit mod- 
ule. Stored commands also can be used to configure a 
time change at a specified time well in advance of the 

20 required time. 

[0050] The audit module 30 can use the following 
queues: (1) Scheduled Queue; (2) Product Tracking 
Queue; and (3) Errors and Exceptions Queue. 
[0051] The Scheduled Queue is sent automatically at 

25 the scheduled report time or when the queue is filled to 
a specified capacity. The Scheduled Queue contains the 
responses to stored commands that are configured to 
be executed. 

[0052] The Product Tracking Queue is used to store 
30 time stamped vend operations when product tracking is 
enabled. The queue includes up to two hundred vend 
events, each of which is six bytes long, as illustrated in 
FIG. 21. 

[0053] The Errors and Exceptions Queue is used to 
35 store the time stamped errors that are configured as 
high or low priority. The queue can store up to one hun- 
dred error events each of which is six bytes long, as 
shown in FIG. 22A. The queue is sent when a high pri- 
ority alarm occurs and also can be sent on demand or 
40 when the queue is filled to a specified capacity. The field 
'Error Type' is defined as shown in FIG. 22B. 

Database Configuration and Data Retrieval 

45 [0054] Database configuration and data retrieval are 
performed using predefined single byte commands. The 
available commands include the following: (1) READ; 
(2) WRITE; (3) CLEAR; (4) TIME STAMP; and (5) PULL/ 
PUSH. The format and syntax for each of the commands 
50 is illustrated in FIG. 23. 

READ Commands 

[0055] A READ command instructs the audit module 
55 to read the requested information and send the results. 
The parameters of the READ command include the in- 
dex to be read and the field within that index. The READ 
command can specify a field within an index or the field 
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across the entire index. The syntax tor a READ com- 
mand is: 

01 'Database' 'Index 1 'Field' where the 'Database' 
field refers to the value of one of the databases or map- 
ping tables. 

[0056] To request information across more than one 
field, one of the indices 8F, 9F or AF is used. The 8F 
and 9F indices are used to request the response without 
the reference attached to the data. The AF index is used 
to request the response with the reference attached to 
the data. When the indices 8F, 9F or AF are used, the 
response includes a byte immediately following the 8F, 
9F or AF to indicate how many instances of the data 
follow. The 8F index is used for selective READ opera- 
tions and is followed by a byte indicating the number of 
indices to be read. The 9F index refers to all information 
without index references. The AF index refers to all in- 
formation with index references. 9F references are used 
for field queries to indicate the entire record is required. 
In this case the data is returned in structure format with 
all information packed. 

[0057] Several examples are now discussed to illus- 
trate READ commands using the format of FIG. 23. To 
read the absolute inventory from index 2 of the Product 
Database, the syntax for the READ command would be 
01 01 02 03, where the value of the Product Database 
is 1 (see FIG. 4) and the absolute inventory is field 3. 
Assuming index 2 of the absolute inventory field of the 
Product Database contains the value of 33 (i.e., 0x21), 
then the response would be 81 01 02 03 00 21 with the 
response command byte now set to 81 . 
[0058] To read the number of vends for all entries in 
the Product Database (without supporting index infor- 
mation), the READ command 01 01 9F 02 can be used, 
assuming that the number of vends is stored in field 2 
of the Product Database. Assuming further that the 
Product Database has four configured indices, the for- 
mat of the response would look like 81 01 9F 04 02 00 
20 00 34 00 21 00 07. The response has the value of 4 
inserted between the 9F and field number 2 to indicate 
that the response includes four repetitions of the re- 
quested field attached. 

[0059] On the other hand, to read the number of vends 
for all entries of the Product Database (with supporting 
index information), a READ command having the syntax 
01 01 AF 02 would be used. The format of the response 
would look like the following: 81 01 AF 04 02 01 00 20 
05 00 34 06 00 21 07 00 07. As before, the value of 4 
inserted between AF and the field number 2 indicates 
there are four repetitions of the requested field attached. 
Each repetition reported includes the index number for 
which the value applies because supporting information 
was requested. 

[0060] To read the absolute inventory for the selected 
indices 1 , 3, 8 and 9 from the Product Database, a READ 
command with the syntax 01 01 8F 04 03 01 03 08 09 
can be used. The number 4 follows 8F in the foregoing 
command to indicate that the command includes a re- 



quest for data from four indices in the absolute inventory 
field 3. The format of the response would look like: 81 
01 8F 04 03 00 01 00 02 00 03 00 04. 
[0061] The READ command can be used to read data 
s stored in other databases and tables as well. 

WRITE Commands 

[0062] A WRITE command can be used to program 
10 fields and indices in the various databases and mapping 
tables. The syntax for a WRITE command is 

02 'Database' 'Index' 'Field' where the 'Database' 
field is the value of one of the databases or mapping 
tables. In some cases, use of the WRITE command may 
15 be prevented with respect to one or more fields within a 
database. A WRITE command directed to a protected 
location will result in a negative acknowledgement 
(NAK). After a WRITE command has been completed, 
the audit module responds with a positive acknowledg- 
ment (ACK) or a negative acknowledgement (NAK) de- 
pending on whether the command was successful. The 
ACK and NAK are included in bit 6 of a response to a 
WRITE command byte. 

[0063] Complete record structures can be written to a 
database using the 9F index. The structures are packed. 
The AF index can be used to write index specific infor- 
mation to a database. Examples of WRITE commands 
are now discussed. 

[0064] To write the value 31 (i.e., 0x1 F) to index 2 of 
the absolute inventory field of the Product Database, a 
WRITE command with the syntax 02 01 02 03 1F can 
be used, where the Product Database has the value 1 , 
and the absolute inventory is field 3 of that database. If 
the write operation is successful, then the response 
would be 82 01 04 03. If, on the other hand, the write 
operation were not successful, then the response would 
be C2 01 04 03. 

[0065] To write the values 31 (0x1 F), 46 (0x2E) and 4 
to the first 3 entries in the Cash Database, a WRITE 
command 02 07 9F 03 01 1 F 00 2E 00 04 00 would be 
used, where the value of the Cash Database is 7, and 
the index 9F is used in a manner analogous to that de- 
scribed above in the section on read commands. If the 
write operation is successful, the response would be 82 
07 9F 03 01 . On other hand, if the write operation were 
not successful, the response would be 02 07 9F 03 01 , 
indicating that the data was not written to the requested 
locations. 

[0066] Similarly, to write the values 1 F, 2E and 04 to 
the Cash Database indices 2, 5, and 9 respectively, the 
WRITE command 02 07 AF 03 01 02 1 F 00 05 2E 00 
09 04 00 would be used, where the AF index is de- 
scribed above. If the write operation is successful, then 
the response would be 82 07 AF 03 01 , whereas if the 
write operation failed, then the response would be C2 
07 AF 03 01. 

[0067] The WRITE command can be used to write da- 
ta to other databases and tables as well. 
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CLEAR, TIME STAMP and Queue PULL/PUSH 
Commands 

[0068] The CLEAR command is used to set all entries 
of a database to zero. The general syntax for the CLEAR 
command is illustrated in FIG. 23. For example, to clear 
the Product Database, the CLEAR command 03 01 9F 
9F would be used. If the clear operation is successful, 
then the response 83 01 9F 9F would be received. Oth- 
erwise, the response C3 01 9F 9F would be received to 
indicate that the clear operation failed. To selectively 
clear fields, the WRITE command should be used to 
write zeros in the selected fields and indices. 
[0069] The TIME STAMP command is used to indi- 
cate the time that data was written to a queue. A time 
stamp is generated when stored commands that have 
the most significant bit of the 'Report Type 1 set are exe- 
cuted. The date and time are provided as a 4-byte 
number following the 04 command reference as shown 
in FIG. 23. 

[0070] The queue PULL/PUSH command is used to 
request data from a queue or to indicate that data is sent 
from a queue. If data from a queue is sent automatically, 
the information is pushed from the audit module 30 to 
the host 34. The format of the queue command is illus- 
trated in FIG. 23, where the 'Blank byte' indicates either 
the number of entries or the length of the queue. The 
Product Tracking and Error and Exceptions queues are 
returned with the number of entries in the queue. The 
scheduled queue is sent with the length of the queue. 
[0071] When a queue is pushed either by a report time 
or high priority error, only the particular queue is sent. 
The host 34 can access other queues by using a queue 
pull command. If the queue is empty the response will 
indicate a length or number of entries of 0. 

Data Transmissions 

[0072] A transmission can be defined as the collection 
of data within one communications session and is based 
on the command/formatting language described above. 
The format of the message protocol is illustrated in FIG. 
24. Multiple commands to perform operations on the 
same database structures are sequential within each 
transmission with a maximum of 1 024 bytes for all forms 
of incoming commands to the audit module 30. Trans- 
missions of outgoing commands from the audit module 
30 can have up to 4096 bytes. The header and trailer 
are determined by the location within the transmission. 
The header starts at the first byte of a transmission. The 
trailer forms the last two bytes of a transmission and is 
a 16-bit CRC calculated over the entire transmission in- 
cluding the header. 

[0073] As shown in FIG. 25, in some implementations 
the audit module 30 can communicate with a host via 
an interface 60 configured for AMPS cellular, Mobitex 
or PSTN communications. An interface 62 for infrared 
communications also can be provided. A local access 



network (LAN) 64 can be used to allow multiple audit 
modules to share a single transceiver, thereby reducing 
the total number of transceivers. 
[0074] When installed in the vending machine, the au- 

5 dit module 30 may receive data from one or more units 
or components in the vending machine. For example, 
the audit module can monitor data from a coin changer 
74, bill validator 76 and/or debit card reader 78, as well 
as the vending machine controller. In some applications, 

10 the audit module 30 can be connected to an external 
adapter, such as a matrix motor monitor (MMM) 66 or a 
linear motor monitor (LMM) 68, to allowthe audit module 
to track product information in a matrix or linear vending 
machine. The audit module also can be configured to 

15 receive signals from a door switch 70 to determine 
whether the vending machine door is open or closed. 
[0075] A direct connect interface 72, based on the 
DEX/UCS standard, is provided to link the audit module 
30 and another vending machine device directly togeth- 

20 er for transferring vending audit type data. The medium 
for the transfer is based upon the DEX/UCS fixed com- 
munications protocol and physical interface. The phys- 
ical layer for DEX communications involves a standard 
RS232C interface. 

25 [0076] In addition to the DEX interface 72, the audit 
module 30 can include a multi-drop bus (MDB) interface 
80 which removably couples the audit module 30 to one 
or more vending machine devices. The command lan- 
guage discussed above can be used to access a device 

30 removably coupled to the audit module. Such devices 
include a vending machine control board, a coin chang- 
er or bill validator, among others. The audit module can 
be configured, for example, to poll the removably cou- 
pled device and request that software or data stored in 

35 the removably coupled device be sent to the audit mod- 
ule which can transfer the requested information to the 
requesting host. Similarly commands can be sent to the 
audit module to update, modify or replace software in 
the removably coupled device. 

40 [0077] Although specific database, table, command 
and transmission formats have been set forth in the fore- 
going description, they are exemplary only. Other for- 
mats can be used and other implementations are within 
the scope of the following claims. 

45 

Claims 

1 . A method of auditing data from a vending machine, 
50 the method comprising: 

providing commands to an audit module con- 
nected to the vending machine, wherein the 
commands are generated externally and indi- 
55 cate a type of vending machine data to be proc- 

essed by the audit module, how the data is to 
be processed by the audit module, and a loca- 
tion in memory in the audit module for storage 
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of that type of vending machine data; and 
configuring the audit module to process vend- 
ing machine data in response to the received 
commands. 

2. The method of claim 1 wherein the commands are 
transmitted to the audit module from a remote host. 

3. The method of claim 1 or 2 including: 

configuring the audit module to report vending 
machine data to a remote host based on the re- 
ceived commands. 

4. The method of any preceding claim including: 

configuring the audit module to store at least 
one command which is to be executed by the audit 
module upon the occurrence of a specified event. 

5. The method of any preceding claim including: 

configuring the audit module to store a stack 
of commands which are to be executed by the audit 
module upon the occurrence of one or more spec- 
ified events. 

6. The method of any preceding claim wherein the 
commands specify vending machine data that is to 
be selectively retained for processing by the audit 
module. 

7. The method of any preceding claim including: 

accessing a removably coupled device in the 
vending machine in response to one or more of the 
commands. 

8. The method of claim 7 wherein the act of accessing 
a removably coupled device includes polling the de- 
vice to retrieve information stored in the removably 
coupled device. 

9. The method of claim 8 further including: 

transferring the requested information from 
the audit module to a host. 

10. The method of claim 7, 8 or 9 wherein the act of 
accessing a removably coupled device includes up- 
dating, modifying or replacing software in the re- 
movably coupled device. 

11. The method of any preceding claim further includ- 
ing: 

reconfiguring at least a portion of memory in 
the audit module in response to received com- 
mands. 

12. The method of claim 11 wherein the act of reconfig- 
uring modifies operation of the audit module. 

13. The method of claim 11 wherein the act of reconfig- 



uring causes the audit module to execute an oper- 
ation with respect to vending machine data. 

14. The method of any preceding claim wherein each 
$ command has a syntax that includes variables 

whose values can be selected from a plurality of op- 
tions. 

15. An audit module arranged for connection to a vend- 
10 ing machine, the audit module comprising: 

a controller and memory, 
wherein the audit module is configured to re- 
ceive externally-generated commands indicat- 
es jng a type of vending machine data to be proc- 
essed by the audit module, how the data is to 
be processed by the audit module, and a loca- 
tion in the audit module memory for storage of 
that type of vending machine data, and wherein 
20 the audit module is configured to process vend- 
ing machine data based on the received com- 
mands. 

16. The audit module of claim 1 5 configured to receive 
25 the commands from a remote host. 

17. The audit module of claim 15 or 16 that can be con- 
figured in response to received commands to report 
vending machine data to a remote host. 

30 

18. The audit module of any one of claims 15 to 17, 
wherein the audit module can store at least one re- 
ceived command to be executed by the audit mod- 
ule upon the occurrence of a specified event. 

35 

19. The audit module of any one of claims 15 to 18, 
wherein the audit module can be configured to store 
a stack of commands which are to be executed by 
the audit module upon the occurrence of one or 

40 more specified events. 

20. The audit module of any one of claims 15 to 19 
wherein the audit module can be configured to se- 
lectively retain specified vending machine data for 

45 subsequent processing in response to the received 
commands. 

21. The audit module of any one of claims 15 to 20 the 
audit module can be configured to access a remov- 

50 ably coupled device in the vending machine in re- 
sponse to one or more of the received commands. 

22. The audit module of claim 21 wherein the audit 
module can be configured, in response to the re- 

55 ceived commands, to poll the removably coupled 
device to retrieve information stored therein. 

23. The audit module of claim 22 wherein the audit 
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module can be configured, in response to the re- 
ceived commands, to transfer requested informa- 
tion to a remote host. 

24. The audit module of any one of claims 21 to 23 5 
wherein the audit module memory can be reconfig- 
ured in response to the received commands. 

25. The audit module of claim 24 wherein operation of 

the audit module is modified in response to the re- 10 
ceived commands. 

26. The audit module of any one of claims 15 to 25 
wherein each command has a syntax that includes 
variables whose values are selected from a plurality 15 
of options. 

27. A vending machine comprising: 

an audit module, wherein the audit module in- 
cludes a controller and memory, and wherein the 20 
audit module is configured to receive externally- 
generated commands indicating a type of vending 
machine data to be processed by the audit module, 
how the data is to be processed by the audit mod- 
ule, and a location in the audit module memory for 25 
storage of that type of vending machine data, and 
wherein the audit module is configured to process 
vending machine data based on the received com- 
mands. 

30 

28. An audit module for a vending machine, the module 
being operable to execute externally-generated 
commands having a predetermined syntax includ- 
ing an instruction-identifying code and a variable. 
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Figure 20A : Stored Command Table 
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Figure 22B : Error Entry Types 
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